Messages, or calls, transmitted within the network are usually queued or buffered, especially during peak hours waiting to be forwarded or processed. Sometimes these calls may be lost or contaminated due to network failures. It is, therefore, useful for a network management system or administrators to know the status of the calls. Status enquiry procedure, or call auditing, is developed to provide a mechanism to obtain a state of a connection, such as the call state, the type of connection being supported, the end state of a point-to-multipoint connection, or certain error conditions.
For example, the Asynchronous Transfer Mode (ATM) communication model provides a status enquiry procedure in the user-network interface (UNI) protocol. According to this protocol, the status enquiry message is sent by a user or the network at any time to solicit a status message from a peer layer 3 entity. A status message is then sent in response to the status enquiry message by the enquired user or network.
A major drawback of this status enquiry procedure is that the status enquiry is done one call at a time and requires multiple (up to eight) messages to be exchanged per call. For large number of calls, the number of exchanged messages may be very high, resulting in diminished call processing capacity and congested network traffic. In addition, the procedure does not provide a way to tag the enquiry. Therefore, it is not clear for the system administrator if a certain call has been audited. As a result, many calls may have to be audited repeatedly, resulting in wasteful time and congested network traffic. When the number of calls to be audited is large, such as typical in ATM switched virtual channel (SVC) calls, the traditional status enquiry procedure degrades network performance significantly.